Base station apparatus and inter-base-station gateway apparatus

ABSTRACT

A base station apparatus (1) is configured to send a first information element to an inter-base-station gateway (3). The first information element explicitly or implicitly indicates whether a relay operation is necessary. The relay operation is an operation in which the inter-base-station gateway (3) relays a data packet destined for or sent from a radio terminal between the base station apparatus (1) and another base station (2). It is thus, for example, possible to contribute to enabling a base station or an inter-base-station gateway to select whether a relay operation by the inter-base-station gateway should be performed at the time of an inter-base-station handover.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a National Stage of International Application No.PCT/JP2015/006366 filed Dec. 22, 2015, claiming priority based onJapanese Patent Application No. 2015-058155 filed Mar. 20, 2015, thecontents of all of which are incorporated herein by reference in theirentirety.

TECHNICAL FIELD

The present disclosure relates to radio communication and in particularto forwarding of user data packets between base stations.

BACKGROUND ART

The 3rd Generation Partnership Project (3GPP) Release 12 specifies an X2Gateway (X2 GW) (see, for example, Non-patent Literature 1). Asdescribed in Non-patent Literature 1, the X2 GW establishes a signaling(i.e., Stream Control Transmission Protocol (SCTP)) connection with eachof a plurality of (H)eNBs and these (H)eNBs exchange signaling messages(i.e., X2AP messages) through the X2 GW. The (H)eNB means an eNodeB or aHome eNodeB. The X2 GW does not terminate X2AP procedures except for theX2AP Message Transfer procedure. That is, X2AP contexts only exist inthe two peer (H)eNBs, which is similar to the case where no X2 GW ispresent. The X2AP contexts define an “X2AP association” between peer(H)eNBs that spans over two SCTP connections.

The X2AP Message Transfer procedure is performed by the X2 GW asfollows. That is, when a source (H)eNB sends an X2AP message (except theX2AP MESSAGE TRANSFER message) to a target (H)eNB through the X2 GW, thesource (H)eNB encapsulates the X2AP message in an X2AP MESSAGE TRANSFERmessage, adds routing information (i.e., RNL Header), then sends theX2AP MESSAGE TRANSFER message to the X2 GW. The routing information(i.e., RNL Header) includes both a target (H)eNB ID and a source (H)eNBID. The X2 GW routes the X2AP MESSAGE TRANSFER message based on thetarget (H)eNB ID.

The X2 interface is an inter-base-station interface in the 3GPP Release8 and subsequent releases. The X2 interface includes a control plane(signaling) interface (i.e., X2-C interface) and a user plane (dataplane) interface (i.e., X2-U interface). The X2-C interface is used, forexample, for preparation of a handover between base stations (i.e., X2handover), control of Dual connectivity (e.g., establishment,modification, and release of a UE context; and management of an X2 userplane tunnel), and various settings and maintenance related to adjacenteNBs. The X2-C interface uses the X2AP protocol and uses the SCTP andthe Internet Protocol (IP) to transfer X2AP signaling messages. The X2APprotocol is referred to as a Radio Network Layer (RNL) protocol and theSCTP/IP, which is used to transfer the X2AP protocol, is referred to asa Transport Network Layer (TNL) protocol.

Meanwhile, the X2-U interface is used, for example, to forward user datapackets from a source (H)eNB to a target (H)eNB during a handover, andtransfer user data packets (i.e., Packet Data Convergence Protocol(PDCP) PDUs) between a Master eNB (MeNB) and a Secondary eNB (SeNB) inDual connectivity. The X2-U interface uses the GPRS Tunnelling ProtocolUser Plane (GTP-U) protocol and uses the User Datagram Protocol (UDP)and the IP to transfer GTP Protocol Data Units (GTP-PDUs). The GTP-Uprotocol is an RNL protocol for the user plane (U-plane) and the UDP/IP,which is used to transfer the GTP-U PDU, is a TNL protocol for theU-plane. The GTP-U and the TNL UDP/IP provide a tunnel mechanism. Thatis, the GTP-U encapsulates a user data packet (e.g., IP packet) with aGTP-U header, and the encapsulated user data packet (i.e., GTP-PDU) istransferred on the TNL UDP/IP layer. The user data packet is alsoreferred to as a T-PDU. Further, although the user data packet (i.e.,T-PDU) encapsulated with the GTP-U header is one of the GTP-PDUs, it isalso referred to as a G-PDU to distinguish it from other GTP-PDUscontaining a signaling message between GTP nodes. Further, each of theG-PDU and the GTP-U PDU (i.e., signaling message) is also referred to asa GTP-U message.

Although the 3GPP Release 12 specifies a transfer of X2AP signalingmessages (X2-C) between two peer (H)eNBs through an X2 GW as describedin Non-patent Literature 1, it does not specify a transfer of user datapackets (X2-U). For this matter, Patent Literatures 1 and 2 disclose atransfer of user data packets between two peer (H)eNBs through an X2 GW.

Patent Literature 1 discloses that an HeNB-GW, which relays S1-MMEsignaling messages and user data packets between a core network (i.e.,Evolved Packet Core (EPC)) and an (H)eNB, also supports the X2-Cinterface and X2-U interface. The HeNB-GW disclosed in Patent Literature1 operates to relay a GTP-PDU encapsulating a user data packet (i.e.,G-PDU) between two peer (H)eNBs. However, Patent Literature 1 does notdescribe details of the G-PDU relay operation performed by the HeNB-GW.

Patent Literature 2 discloses that a G-PDU is transferred between two(H)eNBs through an X2-GW. The X2-GW disclosed in Patent Literature 2assigns a Tunnel Endpoint Identifier (TEID) to each of the two (H)eNBsduring the preparation of a handover, and operates to change the TEIDindicated in the GTP-U header of a received GTP-U PDU from one (H)eNBand send the GTP-U PDU, in which the TEID has been changed, to the other(H)eNB.

CITATION LIST Patent Literature

-   Patent Literature 1: Japanese Unexamined Patent Application    Publication No. 2012-227974-   Patent Literature 2: Japanese Unexamined Patent Application    Publication No. 2013-150204

Non Patent Literature

-   Non-patent Literature 1: 3GPP TS 36.300 V12.4.0 (2014-12), “3rd    Generation Partnership Project; Technical Specification Group Radio    Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA)    and Evolved Universal Terrestrial Radio Access Network (E-UTRAN);    Overall description; Stage 2 (Release 12)”, December 2014

SUMMARY OF INVENTION Technical Problem

In the case where an inter-base-station gateway (e.g., X2-GW) is used,it may be inappropriate if a transfer of user data packets (e.g., PDCPPDUs) between base stations (e.g., DL data forwarding at the time of aninter-base-station handover (e.g., X2 handover) and transferring betweenan MeNB and an SeNB in Dual connectivity) is always performed throughthe X2-GW. For example, when the maximum or effective throughput (i.e.,transmission rate) of the inter-base-station direct path (e.g., X2interface) is sufficiently large, it may be inappropriate to always usethe relay operation by the inter-base-station gateway in view ofincrease in delay. On the other hand, when the load of theinter-base-station direct path is high or when the inter-base-stationdirect path cannot be used for some reason, it may be preferable if therelay operation by the inter-base-station gateway can be selected.Further, it may be preferable if a TNL address (e.g., IP address) of oneof two base stations (e.g., (H)eNBs) can be concealed from the otherwhen a handover is performed between these two base stations. Thisconcealment of the TNL address may be required only for a specific basestation or a specific type of base stations.

In view of above, it may be preferable if a base station (e.g., (H)eNB)or an inter-base-station gateway (e.g., X2-GW) can select whether arelay operation by the inter-base-station gateway (e.g., the X2-GW)should be performed when user data packets are transferred between basestations. However, Patent Literatures 1 and 2 do not disclose anycontrol as to whether the relay operation by the X2 GW should beperformed. Note that the relay operation of user data packets by theinter-base-station gateway (e.g., X2-GW) means a transfer of user datapackets between base stations (e.g., (H)eNBs) through the X2-GW.

One of the objects to be attained by embodiments disclosed herein is toprovide an apparatus, a method, and a program that contribute toenabling a base station (e.g., (H)eNB) or an inter-base-station gateway(e.g., X2-GW) to select whether a relay operation by theinter-base-station gateway (e.g., X2-GW) should be performed. It shouldbe noted that the above-described object is merely one of the objectsintended to be attained by the embodiments disclosed herein. Otherobjects or problems and novel features will be made apparent from thefollowing description and the accompanying drawings.

Solution to Problem

In a first aspect, a base station apparatus includes a memory and atleast one processor coupled to the memory. The at least one processor isconfigured to send a first information element to an inter-base-stationgateway. The first information element explicitly or implicitlyindicates whether a relay operation is necessary. The relay operation isan operation in which the inter-base-station gateway relays a datapacket destined for or sent from a radio terminal between the basestation apparatus and another base station.

In a second aspect, an inter-base-station gateway apparatus includes amemory and at least one processor coupled to the memory. The at leastone processor is configured to receive a first information element fromat least one of a first base station and a second base station. Thefirst information element explicitly or implicitly indicates whether arelay operation is necessary. The relay operation is an operation inwhich the inter-base-station gateway apparatus relays a data packetdestined for or sent from a radio terminal between the first basestation and the second base station.

In a third aspect, a method performed by a base station apparatusincludes sending a first information element to an inter-base-stationgateway. The first information element explicitly or implicitlyindicates whether a relay operation is necessary. The relay operation isan operation in which the inter-base-station gateway relays a datapacket destined for or sent from a radio terminal between the basestation apparatus and another base station.

In a fourth aspect, a method performed by an inter-base-station gatewayapparatus includes receiving a first information element to at least oneof a first base station and a second base station. The first informationelement explicitly or implicitly indicates whether a relay operation isnecessary. The relay operation is an operation in which theinter-base-station gateway apparatus relays a data packet destined foror sent from a radio terminal between the first base station and thesecond base station.

In a fifth aspect, a program includes a set of instructions (softwarecodes) that, when loaded into a computer, causes the computer to performa method according to the above-described third or fourth aspect.

Advantageous Effects of Invention

According to the above-described aspect, it is possible to provide anapparatus, a method, and a program that contribute to enabling a basestation or an inter-base-station gateway to select whether a relayoperation by the inter-base-station gateway should be performed.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows a configuration example of a radio communication systemaccording to some embodiments;

FIG. 2 is a sequence diagram showing an example of a procedure forgiving a notice of necessity for a relay operation according to a firstembodiment;

FIG. 3 is a flowchart showing an example of an operation of a sourcebase station according to the first embodiment;

FIG. 4 is a flowchart showing an example of an operation of aninter-base-station gateway according to the first embodiment;

FIG. 5 is a flowchart showing an example of an operation of a targetbase station according to the first embodiment;

FIG. 6 is a flowchart showing an example of an operation of a targetbase station according to the first embodiment;

FIG. 7 is a table showing an example of combinations of operations of asource base station and an inter-base-station gateway with theiractivation conditions according to the first embodiment;

FIG. 8 is a table showing an example of combinations of operations of asource base station and an inter-base-station gateway with theiractivation conditions according to the first embodiment;

FIG. 9 is a table showing an example of combinations of operations of atarget base station and an inter-base-station gateway with theiractivation conditions according to the first embodiment;

FIG. 10 is a table showing an example of combinations of operations of atarget base station and an inter-base-station gateway with theiractivation conditions according to the first embodiment;

FIG. 11 is a sequence diagram showing an example of a notifyingprocedure of a relay capability according to the first embodiment;

FIG. 12 is a sequence diagram showing an example of a notifyingprocedure of a relay capability according to the first embodiment;

FIG. 13A is a sequence diagram showing an example of a procedure for aninter-base-station handover according to the first embodiment;

FIG. 13B is a sequence diagram showing an example of a procedure for aninter-base-station handover according to the first embodiment;

FIG. 14 shows an example of a modification to an X2AP Message Transfermessage;

FIG. 15A shows another example of a modification to an X2AP MessageTransfer message;

FIG. 15B shows another example of a modification to an X2AP MessageTransfer message;

FIG. 16 is a sequence diagram showing an example of a procedure fornotifying a target base station of an address of an inter-base-stationgateway according to a third embodiment;

FIG. 17A shows an example of a modification to an X2 TNL ConfigurationInfo message;

FIG. 17B shows an example of a modification to an X2 TNL ConfigurationInfo message;

FIG. 18 is a block diagram showing a configuration example of a basestation according to some embodiments; and

FIG. 19 is a block diagram showing a configuration example of aninter-base-station gateway according to some embodiments.

DESCRIPTION OF EMBODIMENTS

Specific embodiments are described hereinafter in detail with referenceto the drawings. The same symbols are assigned to the same orcorresponding elements throughout the drawings, and duplicatedexplanations are omitted as necessary.

Embodiments described below are explained mainly using specific exampleswith regard to a Long Term Evolution (LTE)/LTE-Advanced system. However,these embodiments are not limited to being applied to theLTE/LTE-Advanced system and may also be applied to other mobilecommunication networks or systems such as a 3GPP Universal MobileTelecommunications System (UMTS), a 3GPP2 CDMA2000 system, a GlobalSystem for Mobile communications (GSM (Registered Trademark))/Generalpacket radio service (GPRS) system, and a WiMAX system.

First Embodiment

FIG. 1 shows a configuration example of a radio communication systemaccording to some embodiments including this embodiment. In the exampleshown in FIG. 1, the radio communication system includes an (H)eNB 1, an(H)eNB 2, an X2 GW 3, and an EPC 4. The X2 GW 3 is configured toestablish an SCTP connection with each of the (H)eNBs 1 and 2 to relaysignaling messages (i.e., X2AP messages) between the (H)eNBs 1 and 2.The X2 GW 3 is further configured to establish a GTP-U tunnel with eachof the (H)eNBs 1 and 2 to relay user data packets between the (H)eNBs 1and 2. Each of the (H)eNBs 1 and 2 includes an X2-C interface with theX2 GW 3 and an S1 interface with the EPC 4. Note that an HeNB-GW may beused between the EPC 4 and at least one of the (H)eNBs 1 and 2. ThisHeNB-GW relays S1-MME signaling and user data packets (S1-U) between theEPC 4 and at least one of the (H)eNBs 1 and 2. This embodiment focusesmainly on a handover of an UE from the (H)eNB 1 to the (H)eNB 2.Accordingly, the (H)eNB 1 and the (H)eNB 2 may be referred to as thesource (H)eNB and the target (H)eNB, respectively.

In this embodiment, at least one of the (H)eNBs 1 and 2 is configured tosend a first Information Element (IE) to the X2 GW 3. This firstinformation element explicitly or implicitly indicates whether a relayoperation by the X2 GW 3 is necessary for forwarding user data packetsof a radio terminal (User Equipment (UE)). In some implementations, whenthe UE is handed over from the (H)eNB 1 to the (H)eNB 2, at least one ofthe source (H)eNB 1 and the target (H)eNB 2 sends this first informationelement. In some implementations, the (H)eNB 1, the (H)eNB 2 and the UEsupport Dual Connectivity, and at least one of the (H)eNBs 1 and 2 sendsthe first information element when a bearer for the UE is established.

The relay operation by the X2 GW 3 includes transferring user datapackets (i.e., T-PDUs) through the X2-U interface (i.e., GTP-U tunnel)101 between the (H)eNB 1 and the X2 GW 3 and the X2-U interface (i.e.,GTP-U tunnel) 102 between the (H)eNB 2 and the X2 GW 3. This relayoperation, in which the X2 GW 3 relays user data packets, may includetransferring user data packets each encapsulated with a GTP-U header(i.e., G-PDUs). The relay operation by the X2 GW 3 can also be referredto as an X2-U relay, a U-plane relay, a GTP-U relay, or a user planeconcentration.

That is, the first information element is an explicit or implicitindication indicating necessity for a U-plane relay by the X2 GW 3. Insome implementations, this indication is flag information that is set todifferent values according to whether the relay operation by the X2 GW 3is necessary. Alternatively, in some implementations, this indication isan explicit or implicit relay request that is transmitted when the relayoperation by the X2 GW 3 is necessary and is not transmitted when therelay operation is unnecessary. Alternatively, in some implementations,this indication is a combination of a plurality of information elements.

For example, as shown in the below specific examples, this indicationmay include an information element (e.g., Direct Path Availability IE orDirect Path Unavailability IE) that indicates availability of a directpath 100 between the (H)eNBs 1 and 2. For example, the availability ofthe direct path 100 may be set in advance in the (H)eNBs 1 and 2 by anoperator or an Operations, Administration and Maintenance (OAM).Alternatively, the availability of the direct path 100 may bedynamically determined by the (H)eNBs 1 and 2. For example, when thedirect path 100 is available but its throughput is low or when the loadof the direct path 100 is high, the (H)eNBs 1 and 2 may determine thatthe direct path 100 cannot be used. This indication may be, for example,a combination of an information element indicating the availability ofthe direct path 100 and an information element (e.g., DL Forwarding IEor Uplink (UL) GTP Tunnel Endpoint IE) indicating necessity of dataforwarding.

FIG. 2 is a sequence diagram showing an example (Process 200) of aprocedure for notifying the X2 GW 3 of necessity for the relayoperation. In Block 201, the (H)eNB 1 or 2 sends an X2AP MessageTransfer message to the X2 GW 3. This X2AP Message Transfer messagecarries an X2AP Handover Request message from the source (H)eNB 1 to thetarget (H)eNB 2, or an X2AP Handover Request Acknowledge message fromthe target (H)eNB 2 to the source (H)eNB 1. Furthermore, this X2APMessage Transfer message includes an indication explicitly or implicitlyindicating necessity for the X2-U relay operation by the X2 GW 3. The X2GW 3 can recognize whether it should prepare for the X2-U relay based onthis indication.

Further, in the example shown in FIG. 2, the X2 GW 3 receives theindication indicating necessity of the X2-U relay operation togetherwith the X2AP Message Transfer message carrying the Handover Requestmessage or the Handover Request Acknowledge message. Therefore, the X2GW 3 can easily prepare for a GTP-U tunnel necessary for the X2-U relayby referring to this X2AP Message Transfer message.

As can be understood from the above description, in this embodiment, atleast one of the (H)eNBs 1 and 2 is configured to send to the X2 GW 3the indication explicitly or implicitly indicating whether the U-plane(X2-U) relay by the X2 GW 3 is necessary. Therefore, the X2 GW 3 canrecognize whether it should perform the U-plane (X2-U) relay based onthis indication.

Further, in this embodiment, at least one of the (H)eNBs 1 and 2 may beconfigured to, when transferring of user data packets of a radioterminal (UE) from the (H)eNB 1 to the (H)eNB 2 is needed, determinewhether to use the relay operation by the X2 GW 3 for forwarding theseuser data packets of the UE. In other words, the (H)eNBs 1 and 2 may beconfigured to select which of the relay path (101 and 102) through theX2 GW 3 and the direct path (100) will be used for forwarding user datapackets from the (H)eNB 1 to the (H)eNB 2. When they do not use therelay operation by the X2 GW 3, the source (H)eNB 1 may forward userdata packets to the target (H)eNB 2 via the direct path between the(H)eNBs 1 and 2 (i.e., X2-U interface (GTP-U tunnel) 100).

In some implementations, when the source (H)eNB 1 determines initiationof a handover of a UE to the (H)eNB 2, it may also determine whether touse the U-plane (X2-U) relay operation by the X2 GW 3. In someimplementations, when the target (H)eNB 2 receives a handover requestfrom the source (H)eNB 1, it may determine whether to use the U-plane(X2-U) relay operation by the X2 GW 3. In some implementations, when the(H)eNB 1 receives a request for establishing a bearer for an UE thatsupports Dual Connectivity (e.g., S1AP: Initial Context Setup Request)from the EPC 4, it may determine whether to use the U-plane (X2-U) relayoperation by the X2 GW 3. Alternatively, determination of whether theU-plane (X2-U) relay operation by the X2 GW 3 is to be used or not isperformed in advance per pair of (H)eNBs.

In some implementations, one or both of the (H)eNBs 1 and 2 may selectwhether to use the U-plane (X2-U) relay operation by the X2 GW 3according to the state of the direct path 100 (e.g., availability of thedirect path 100, throughput of the direct path 100, or load of thedirect path 100). In other words, one or both of the (H)eNBs 1 and 2 mayconsider the state of the direct path 100 when determining whether touse (or request) the U-plane (X2-U) relay operation by the X2 GW 3.

For example, when the maximum or effective throughput (or transmissionrate) of the inter-base-station direct path 100 is larger thanthroughput of the path 101 (or 102) between the (H)eNB 1 (or 2) and theX2 GW 3, it may not be appropriate to use the relay operation by theinter-base-station gateway in view of increase in delay. Therefore, whenthe throughput of the inter-base-station direct path 100 is sufficientlylarger than that of the path 101 between the (H)eNB 1 and the X2 GW 3 orlarger than that of the path 102, the (H)eNB 1 or 2 may determine not touse the U-plane (X2-U) relay operation by the X2 GW 3. In this way, itis possible to prevent increase in delay that would otherwise be causedby the unnecessary U-plane relay.

In some implementations, the (H)eNB 1 may use the U-plane (X2-U) relayoperation by the X2 GW 3 when it is necessary to conceal the TNL address(e.g., IP address) of the (H)eNB 1 from the (H)eNB 2, and may performforwarding through the direct path 100 when it is unnecessary to concealits TNL address. Similarly, the (H)eNB 2 may select whether to use theU-plane (X2-U) relay operation by the X2 GW 3 based on necessity forconcealing the TNL address (e.g., IP address) of the (H)eNB 2 from the(H)eNB 1. In other words, one or both of the (H)eNBs 1 and 2 mayconsider the necessity for concealing the TNL address when determiningwhether to use (or request) the U-plane (X2-U) relay operation by the X2GW 3.

For example, the source (H)eNB 1 may need to conceal its TNL address(e.g., IP address) from the target (H)eNB 2 when performing a handover.Conversely, the target (H)eNB 2 may need to conceal its TNL address(e.g., IP address) from the source (H)eNB 1. The TNL address may berequired to be concealed only from a specific base station or a specifictype of base stations.

HeNBs are installed in premises or buildings of end-users, rather thanin buildings (sites) administered by telecommunications carriers.Accordingly, there is a risk that HeNBs may be altered by malicioususers and, thus it may be hard to ensure sufficient security for HeNBs.Therefore, providing the X2-U TNL address of a macro eNB to an HeNB atthe time of a handover could lead to a security risk such as a Denial ofService (DoS) attack to the macro eNB. For example, when the source(H)eNB 1 is a macro eNB and the target (H)eNB 2 is an HeNB, the source(H)eNB 1 may determine to use the U-plane (X2-U) relay operation by theX2 GW 3. In contrast to this, when the source (H)eNB 1 is a macro eNBand the target (H)eNB 2 is also a macro eNB, the source (H)eNB 1 maydetermine not to use the U-plane (X2-U) relay operation by the X2 GW 3.In this way, it is possible to prevent a security risk that wouldotherwise arise if an HeNB is informed of an X2-U TNL address of a macroeNB.

In some implementations, one or both of the (H)eNBs 1 and 2 may selectwhether to use the U-plane (X2-U) relay operation by the X2 GW 3 basedon the U-plane Relay Capability of the X2 GW 3. In other words, one orboth of the (H)eNBs 1 and 2 may consider the presence or absence of theU-plane capability of the X2 GW 3 when determining whether to use (orrequest) the U-plane (X2-U) relay operation by the X2 GW 3.

As can be understood from the above description, in this embodiment, atleast one of the (H)eNBs 1 and 2 may be configured to determine whetherto use the U-plane (X2-U) relay operation by the X2 GW 3 when a UE ishanded over from the (H)eNB 1 to the (H)eNB 2. In this way, at least oneof the (H)eNBs 1 and 2 can select whether to use the U-plane (X2-U)relay operation by the X2 GW 3.

Next, a specific example of operations of the source (H)eNB 1, the X2 GW3, and the target (H)eNB 2 are described. FIG. 3 is a flowchart showingan example (Process 300) of an operation of the source (H)eNB 1. InBlock 301, the (H)eNB 1 determines initiation of a handover of a UE tothe target (H)eNB 2. In Block 302, the (H)eNB 1 determines whether theU-plane (X2-U) relay operation by the X2 GW 3 is necessary at the timeof the handover. When the U-plane (X2-U) relay operation is necessary(YES at Block 302), the source (H)eNB 1 incorporates an explicit orimplicit relay request into a transfer message (i.e., X2AP MessageTransfer message) that carries a handover request (i.e., HandoverRequest message) (Block 303). In Block 304, the source (H)eNB 1 sends tothe X2 GW 3 the transfer message, which carries the handover request andcontains the relay request. On the other hand, when the U-plane (X2-U)relay operation is unnecessary (NO at Block 302), the source (H)eNB 1sends to the X2 GW 3 the transfer message, which carries the handoverrequest, but does not contain the relay request (Block 305).

FIG. 4 is a flowchart showing an example (Process 400) of an operationof the X2 GW 3. In Block 401, the X2 GW 3 receives a transfer message(i.e., X2AP Message Transfer message) carrying a handover request (i.e.,Handover Request message) from the source (H)eNB 1. In Block 402, the X2GW 3 checks whether the received transfer message includes a relayrequest or not. When the transfer message includes the relay request(YES at Block 402), the X2 GW 3 adds in the transfer message, whichcarries the handover request, an indication indicating that the U-plane(X2-U) relay by the X2 GW 3 is to be performed and then sends thistransfer message to the target (H)eNB 2.

In some implementations, this indication indicating that the U-plane(X2-U) relay by the X2 GW 3 is to be performed may be simple flaginformation indicating whether the U-plane (X2-U) relay is to beperformed or not. Additionally or alternatively, as shown in Block 403in FIG. 4, this indication indicating that the U-plane (X2-U) relay bythe X2 GW 3 is to be performed may include an endpoint configuration ofthe X2 GW 3 side regarding an X2 transport bearer (i.e., GTP-U bearer).The endpoint configuration includes a TNL address (e.g., IP address) anda TEID. This endpoint configuration may include only a DL GTP tunnelendpoint configuration regarding an X2 transport bearer used forforwarding downlink (DL) user data packets, or may further include a ULGTP tunnel endpoint configuration regarding an X2 transport bearer usedfor forwarding uplink (UL) user data packets.

The above-described operation in which the X2 GW 3 sends the endpointconfiguration of the X2 GW 3 side regarding the X2 transport bearer(s)(i.e., GTP-U bearer(s)) to the target (H)eNB 2 together with thetransfer message carrying the handover request provides, for example,the following advantages. In some implementations, the target (H)eNB 2may have Access Control List (ACL) functionality. When the ACLfunctionality is applied to the target (H)eNB 2, the target (H)eNB 2accepts a connection from a sending node only when the source address ofthe sending node is already known in the target (H)eNB 2. Accordingly,if the target (H)eNB 2 does not know the X2-U TNL address of the X2 GW3, the target (H)eNB 2 may discard TNL UDP/IP packets that carriesG-PDUs and are transmitted from the X2 GW 3 because of its ACLfunctionality. To prevent this, the X2 GW 3 preferably notifies thetarget (H)eNB 2 of the endpoint configuration of the X2 GW 3 sideregarding the X2 transport bearer (i.e., GTP-U bearer) in advance,though the X2 GW 3 is on the upstream side of the data forwarding. Inthis way, the target (H)eNB 2 can update its ACL so as to accept aconnection from the X2-U TNL address of the X2 GW 3. The ACL can also bereferred to as a packet filter or a firewall configuration.

Referring back to FIG. 4, when the transfer message does not include therelay request (No at Block 402), the X2 GW 3 sends the transfer messagereceived from the source (H)eNB 1 to the target (H)eNB 2 without addingany information thereto (Block 404). That is, the transfer message sentin Block 404 does not include the indication indicating that the U-plane(X2-U) relay by the X2 GW 3 is to be performed.

FIG. 5 is a flowchart showing an example (Process 500) of an operationof the target (H)eNB 2. In Block 501, the target (H)eNB 2 receives atransfer message (i.e., X2AP Message Transfer message) carrying ahandover request (i.e., Handover Request message) from the X2 GW 3. InBlock 502, the target (H)eNB 2 checks whether the received transfermessage includes an endpoint configuration of the X2 GW 3 side regardingan X2 transport bearer (i.e., GTP-U bearer). When the transfer messageincludes the endpoint configuration of the X2 GW 3 side (YES at Block503), the target (H)eNB 2 updates its ACL so as to accept a connectionfrom the X2-U TNL address of the X2 GW 3.

In Block 504, the target (H)eNB 2 sends a transfer message (i.e., X2APMessage Transfer message) carrying a handover request acknowledgement(i.e., Handover Request Acknowledge message) to the X2 GW 3. Thehandover request acknowledgement (i.e., Handover Request Acknowledgemessage) includes a DL GTP tunnel endpoint configuration of the target(H)eNB 2. Further, when UL data forwarding is performed in addition tothe DL data forwarding, the handover request acknowledgement (i.e.,Handover Request Acknowledge message) includes a UL GTP tunnel endpointconfiguration of the target (H)eNB 2. The DL GTP tunnel endpointconfiguration of the target (H)eNB 2 includes a TNL address and a TEIDregarding a GTP-U tunnel for receiving DL user data packets forwardedfrom the source (H)eNB 1. The UL GTP tunnel endpoint configuration ofthe target (H)eNB 2 includes a TNL address and a TEID regarding a GTP-Utunnel for receiving a UL user data packet forwarded from the source(H)eNB 1.

Note that the transfer message carrying the handover request acknowledgemessage sent in Block 504 may include an additional information elementindicating a GTP tunnel endpoint configuration of the target (H)eNB 2which is the same as that described in the handover request acknowledgemessage. Although this message structure is redundant, it has anadvantage that the X2 GW 3 does not have to decode or refer to thehandover request acknowledge message.

The operations of the source (H)eNB 1, the X2 GW 3, and the target(H)eNB 2 shown in FIGS. 3 to 5 are merely examples and may be modifiedas appropriate. For example, the message used to send the relay requestin FIG. 3 may be an X2AP message other than the X2AP Message Transfermessage. For example, the relay request may be embedded in the HandoverRequest message that is carried by the X2AP Message Transfer message.With regard to FIG. 4, the message used to send the endpointconfiguration of the X2 GW 3 may be an X2AP message other than the X2APMessage Transfer message. For example, the endpoint configuration of theX2 GW 3 may be embedded in the Handover Request message that is carriedby the X2AP Message Transfer message.

FIGS. 3 to 5 show examples in which the source (H)eNB 1 determineswhether to use (or request) the U-plane (X2-U) relay by the X2 GW 3 atthe time of a handover. Similarly, when receiving the handover requestfrom the source (H)eNB 1 through the X2 GW 3, the target (H)eNB 2 maydetermine whether to use (or request) the U-plane (X2-U) relay by the X2GW 3. That is, the target (H)eNB 2 may determine necessity of theU-plane (X2-U) relay by the X2 GW 3 independently from the determinationof necessity of the U-plane (X2-U) relay made by the source (H)eNB 1.

FIG. 6 is a flowchart showing an example (Process 600) of an operationincluding a determination by the target (H)eNB 2 of the necessity of theU-plane (X2-U) relay. In Block 601, the target (H)eNB 2 receives atransfer message (i.e., X2AP Message Transfer message) carrying ahandover request (i.e., Handover Request message) from the X2 GW 3. InBlock 602, the target (H)eNB 2 determines whether the U-plane (X2-U)relay operation by the X2 GW 3 is necessary. When the U-plane (X2-U)relay operation is necessary (YES at Block 602), the target (H)eNB 2incorporates an explicit or implicit relay request into a transfermessage (i.e., X2AP Message Transfer message) carrying a handoverrequest acknowledgement (i.e., Handover Request Acknowledge message)(Block 603). In Block 604, the target (H)eNB 2 sends to the X2 GW 3 thetransfer message, which carries the handover request acknowledgement andincludes the relay request. On the other hand, when the U-plane (X2-U)relay operation is unnecessary (NO at Block 602), the target (H)eNB 2sends to the X2 GW 3 the transfer message, which carries the handoverrequest acknowledgement, but does not include the relay request (Block605).

The operation in the X2 GW 3 when it receives from the target (H)eNB 2the transfer message which carries the handover request acknowledgementand includes the relay request may be similar to that shown in FIG. 4.However, as described above with reference to FIG. 5, the handoverrequest acknowledgement (i.e., Handover Request Acknowledge message)includes the GTP tunnel endpoint configuration of the target (H)eNB 2.In some implementations, in the process corresponding to Block 403, theX2 GW 3 may rewrite the GTP tunnel endpoint configuration of the target(H)eNB 2 embedded in the Handover Request Acknowledge message with a GTPtunnel endpoint configuration of the X2 GW 3.

Alternatively, in the process corresponding to Block 403, the X2 GW 3may not make any modification to the GTP tunnel endpoint configurationof the target (H)eNB 2 embedded in the Handover Request Acknowledgemessage and may incorporate, into the X2AP Message Transfer message, anadditional information element indicating the endpoint configuration ofthe X2 GW 3. In this case, the source (H)eNB 1 may update its X2transport bearer context in accordance with the additional informationelement and ignore the GTP tunnel endpoint configuration of the target(H)eNB 2 described in the Handover Request Acknowledge message.

Note that when the U-plane (X2-U) relay by the X2 GW 3 is performed toconceal the TNL address of the target (H)eNB 2 from the source (H)eNB 1,the X2 GW 3 preferably modifies the GTP tunnel endpoint configuration ofthe target (H)eNB 2 described in the Handover Request Acknowledgemessage. In this way, it is possible to certainly conceal the TNLaddress of the target (H)eNB 2 from the source (H)eNB 1.

FIGS. 3 to 6 show specific examples of the operations of the (H)eNBs 1and 2 and the X2 GW 3 in a handover. However, as can be understood fromthe above description, the specific examples of the operations of the(H)eNBs 1 and 2 and the X2 GW 3 described with reference to FIGS. 3 to 6may be applied to the case when a bearer related to a UE supporting DualConnectivity is established. For example, the (H)eNB 1 may determinewhether to use the U-plane (X2-U) relay operation by the X2 GW 3 inresponse to receiving from the EPC 4 a request for establishing a bearerrelated to a UE supporting Dual Connectivity. Then, the (H)eNB 1 mayincorporate the explicit or implicit relay request into a transfermessage (i.e., X2AP Message Transfer message) carrying an X2AP messagefor establishing a UE context for Dual Connectivity.

Next, specific examples of operations of the source (H)eNB 1 and the X2GW 3, and their activation conditions are described with reference toFIGS. 7 and 8. FIG. 7 is a table showing an example of combinations ofoperations of the source (H)eNB 1 and the X2 GW 3 with their activationconditions. In the example shown in FIG. 7, the source (H)eNB 1considers the availability of the direct path 100 (Direct PathAvailability) and the relay capability of the X2 GW 3 (U-plane RelayCapability) to determine whether to use (or request) the U-plane (X2-U)relay.

In the Case 1 shown in FIG. 7, the direct path 100 is available and theX2 GW 3 has the relay capability. In the Case 2 shown in FIG. 7, thedirect path 100 is available and the X2 GW 3 does not have the relaycapability. In the Cases 1 and 2, since the direct path 100 isavailable, the source (H)eNB 1 does not incorporate the explicit orimplicit relay request to the X2 GW 3 into the X2AP Message Transfermessage (carrying the Handover Request message). Therefore, the X2 GW 3does not perform the U-plane (X2-U) relay for DL data forwarding.

In the Case 3 shown in FIG. 7, the direct path 100 is unavailable andthe X2 GW 3 has the relay capability. In the Case 3, since the X2 GW 3has the relay capability, though the direct path 100 is unavailable, thesource (H)eNB 1 incorporates the explicit or implicit relay request tothe X2 GW 3 into the X2AP Message Transfer message (carrying theHandover Request message). Therefore, the X2 GW 3 performs the U-plane(X2-U) relay for DL data forwarding.

In the Case 4 shown in FIG. 7, the direct path 100 is unavailable andthe X2 GW 3 does not have the relay capability. In the Case 4, sinceX2-U data forwarding cannot be performed, the source (H)eNB 1 does notincorporate the explicit or implicit relay request to the X2 GW 3 intothe X2AP Message Transfer message (carrying the Handover Requestmessage). Therefore, the X2 GW 3 does not perform the U-plane (X2-U)relay for DL data forwarding.

Note that as already described, in some implementations, the implicitrelay request (or the relay indication) to the X2 GW 3 may include acombination of a plurality of information elements. For example, asshown in FIG. 8, the implicit relay request (or the relay indication) tothe X2 GW 3 may be a combination of the Direct Path Unavailability IEand the DL Forwarding IE. The Direct Path Unavailability IE shown inFIG. 8 is set when the direct path 100 is unavailable. The Direct PathUnavailability IE may be one-bit flag information. The DL Forwarding IEshown in FIG. 8 may be the DL Forwarding IE contained in the X2AP:Handover Request message specified in the current 3GPP specifications,or may be an information element newly added in the X2AP MessageTransfer message.

The Cases 1 to 4 shown in FIG. 8 correspond to the Cases 1 to 4 shown inFIG. 7, respectively. That is, in the Case 1 shown in FIG. 8, the directpath 100 is available and the X2 GW 3 has the relay capability. In theCase 2 shown in FIG. 8, the direct path 100 is available and the X2 GW 3does not have the relay capability. In the Cases 1 and 2, since thedirect path 100 is available, the source (H)eNB 1 does not set theDirect Path Unavailability IE. However, the source (H)eNB 1 sets the DLForwarding IE to inform the target (H)eNB 2 that DL forwarding (throughthe direct path 100) is to be performed.

In the Case 3 shown in FIG. 8, the direct path 100 is unavailable andthe X2 GW 3 has the relay capability. In the Case 3, since the directpath 100 is unavailable, the source (H)eNB 1 sets the Direct PathUnavailability IE. Further, in the Case 3, since the X2 GW 3 has therelay capability, though the direct path 100 is unavailable, the source(H)eNB 1 determines that it can perform DL forwarding through the X2 GW3 and, accordingly, sets the DL Forwarding IE to inform the target(H)eNB 2 that DL forwarding (through the X2 GW 3) is to be performed.

In the Case 4 shown in FIG. 8, the direct path 100 is unavailable andthe X2 GW 3 does not have the relay capability. Therefore, in the Case4, the source (H)eNB 1 sets the Direct Path Unavailability IE but doesnot set the DL Forwarding IE.

In the example shown in FIG. 8, the X2 GW 3 refers to the Direct PathUnavailability IE and the DL Forwarding IE, and performs the U-Plane(X2-U) relay for DL data forwarding when both of the two informationelements are set. Therefore, similarly to the example shown in FIG. 7,the U-Plane (X2-U) relay for DL data forwarding is performed only in theCase 3 in FIG. 8 and is not performed in the Cases 1, 2 and 4 in FIG. 8.

Next, specific examples of operations of the target (H)eNB 2 and the X2GW 3, and their activation conditions are described with reference toFIGS. 9 and 10. FIG. 9 is a table showing an example of combinations ofoperations of the target (H)eNB 2 and the X2 GW 3 with their activationconditions. The example related to the target (H)eNB 2 shown in FIG. 9corresponds to the example related to the source (H)eNB 1 shown in FIG.7. Therefore, the U-Plane (X2-U) relay for UL data forwarding isperformed only in the Case 3 in FIG. 9 and is not performed in the Cases1, 2 and 4 in FIG. 9.

In the example shown in FIG. 10, the implicit relay request (or therelay indication) to the X2 GW 3 from the target (H)eNB 2 is acombination of the Direct Path Unavailability IE and the UL GTP TunnelEndpoint IE. The UL GTP Tunnel Endpoint IE shown in FIG. 10 may be theUL GTP Tunnel Endpoint IE contained in an X2AP: Handover RequestAcknowledge message specified in the current 3GPP specifications, or maybe an information element newly added in the X2AP Message Transfermessage.

The example related to the target (H)eNB 2 shown in FIG. 10 correspondsto the example related to the source (H)eNB 1 shown in FIG. 8, exceptfor the difference between the DL Forwarding IE and the UL GTP TunnelEndpoint IE. That is, in the example shown in FIG. 10, the X2 GW 3refers to the Direct Path Unavailability IE and the UL GTP TunnelEndpoint IE, and performs the U-Plane (X2-U) relay for UL dataforwarding when both of the two information elements are set. Therefore,the U-Plane (X2-U) relay for UL data forwarding is performed only in theCase 3 in FIG. 10 and is not performed in the Cases 1, 2 and 4 in FIG.10.

FIGS. 7 to 10 show specific examples of the operations of the (H)eNBs 1and 2 and the X2 GW 3 in a handover. However, as can be understood fromthe above description, the specific examples of the operations of the(H)eNBs 1 and 2 and the X2 GW 3 described with reference to FIGS. 7 to10 may be applied when a bearer related to a UE supporting DualConnectivity is established.

In the examples described with reference to FIGS. 7 to 10, the (H)eNBs 1and 2 consider the presence or absence of the relay capability of the X2GW 3 when determining whether to use (or request) the U-plane (X2-U)relay. The presence or absence of the relay capability of the X2 GW 3may be set in advance in the (H)eNBs 1 and 2 by an operator or anoperations, administration and maintenance (OAM). Alternatively, the X2GW 3 may notify the (H)eNBs 1 and 2 of the presence or absence of itsrelay capability. Specifically, the X2 GW 3 may send to the (H)eNBs 1and 2 a signaling message including an information element (IE)indicating the presence or absence of its relay capability. In someimplementations, as shown in FIGS. 11 and 12, the X2 GW 3 may inform the(H)eNBs 1 and 2 of its relay capability during a procedure forregistering the (H)eNBs 1 and 2 in the X2 GW 3.

FIG. 11 is a sequence diagram showing an example (Process 1100) of aprocedure in which the X2 GW 3 notifies the (H)eNBs 1 and 2 of thepresence or absence of its relay capability. In Block 1101, the (H)eNBs1 (2) sends a registration request to the X2 GW 3 ((H)eNB registration).The X2 GW 3 stores mapping of the identifier of the sender (H)eNB (i.e.,Global eNB ID) included in the registration request and the TNL address(e.g., IP address) of the sender (H)eNB used for the transmission of theregistration request. Then, in Block 1102, the X2 GW 3 sends a responseto the registration request ((H)eNB registration response). Thisresponse includes an information element indicating the presence orabsence of the relay capability of the X2 GW 3 (U-plane RelayCapability). The (H)eNB 1 (2) receives the response sent in Block 1102and thereby recognizes the presence or absence of the U-plane (X2-U)relay capability of the X2 GW 3.

FIG. 12 is a sequence diagram showing another example (Process 1200) ofa procedure in which the X2 GW 3 notifies the (H)eNBs 1 and 2 of thepresence or absence of the relay capability. In the 3GPP Release 12, anX2AP Message Transfer message is used to register an (H)eNB in an X2 GW.Similarly to the 3GPP Release 12, FIG. 12 shows an example in which anX2AP Message Transfer message is used. That is, in Block 1201, the(H)eNB 1 (2), which requests its registration, sends an X2AP MessageTransfer message. This X2AP Message Transfer message contains a Source(H)eNB ID within its RNL Header IE, but it does not contain a Target(H)eNB ID within the RNL Header IE and also does not contain any X2APMessage. In Block 1202, the X2 GW 3 sends a modified X2AP MessageTransfer message. This modified X2AP Message Transfer message contains aTarget (H)eNB ID within its RNL Header IE and also contains anewly-defined U-plane Relay Capability IE, but it does not contain aSource (H)eNB ID within the RNL Header IE and also does not contain anyX2AP Message. The (H)eNBs 1 (2) receives the X2AP Message Transfermessage sent in Block 1202 and thereby recognizes the presence orabsence of the U-plane (X2-U) relay capability of the X2 GW 3.

FIGS. 13A and 13B are sequence diagrams showing an example (Process1300) of an X2 handover procedure according to this embodiment. Theprocedure shown in FIGS. 13A and 13B is similar to an ordinary X2handover procedure through an X2 GW, except that user data packets isforwarded from the source (H)eNB 1 to the target (H)eNB 2 through the X2GW 3 (Blocks 1307 and 1308). That is, in Block 1301, the source (H)eNB 1sends to the X2 GW 3 an X2AP Message Transfer message carrying aHandover Request message. As already described, this X2AP MessageTransfer message may contain an information element explicitly orimplicitly indicating the necessity of the U-plane (X2-U) relay. InBlock 1302, the X2 GW 3 transfers the X2AP Message Transfer messagecarrying the Handover Request message to the target (H)eNB 2. As alreadydescribed, the X2 GW 3 may update an information element in the X2APMessage Transfer message transferred in Block 1302 (or add aninformation element in the X2AP Message Transfer message) according towhether to perform the U-plane (X2-U) relay.

In Block 1303, the target (H)eNB 2 sends to the X2 GW 3 an X2AP MessageTransfer message carrying a Handover Request Acknowledge message. Asalready described, this X2AP Message Transfer message may include aninformation element explicitly or implicitly indicating the necessity ofthe U-plane (X2-U) relay. In Block 1304, the X2 GW 3 transfers the X2APMessage Transfer message carrying the Handover Request Acknowledgemessage to the source (H)eNB 1. As already described, the X2 GW 3 mayupdate an information element in the X2AP Message Transfer messagetransferred in Block 1304 (or add an information element in the X2APMessage Transfer message) according to whether to perform the U-plane(X2-U) relay.

In response to reception of the Handover Request Acknowledge message,the source (H)eNB 1 sends a Handover Command to an UE (not shown). InBlock 1305, the source (H)eNB 1 sends to the X2 GW 3 an X2AP MessageTransfer message carrying an SN Status Transfer message. The SN StatusTransfer message indicates a Sequence Number (SN) of an uplink/downlinkPacket Data Convergence Protocol (PDCP) PDU of which the delivery to theUE has not been completed. In Block 1306, the X2 GW 3 transfers the X2APMessage Transfer message carrying the SN Status Transfer message to thetarget (H)eNB 2.

In Blocks 1307 and 1308, the source (H)eNB 1 forwards theuplink/downlink user data packet(s), of which the delivery to the UE hasnot been completed, to the target (H)eNB 2 through the X2 GW 3. That is,in Block 1307, the source (H)eNB 1 sends to the X2 GW 3, through a GTP-Utunnel between the source (H)eNB 1 and the X2 GW 3, a G-PDU(s) whichencapsulates the uplink/downlink user data packet(s). In Block 1308, theX2 GW 3 transfers the G-PDU(s) received from the source (H)eNB 1 to thetarget (H)eNB 2 through a GTP-U tunnel between the target (H)eNB 2 andthe X2 GW 3.

In the data forwarding in Blocks 1307 and 1308, the X2 GW 3 updates thesource TNL address (i.e., TNL address of the source (H)eNB 1) assignedto the G-PDU(s) received from the source (H)eNB 1 by the TNL address ofthe X2 GW 3 and also updates the source TEID (i.e., TEID of the source(H)eNB 1) by the TEID of the X2 GW 3. Further, the X2 GW 3 updates thetarget TNL address (i.e., TNL address of the X2 GW 3) assigned to theG-PDU(s) received from the source (H)eNB 1 by the TNL address of the(H)eNB 2 and also updates the target TEID (i.e., TEID of the X2 GW 3) bythe TEID of the target (H)eNB 2.

In Block 1309, the target (H)eNB 2 receives a Handover Confirm messagefrom the UE. As a result of this, the UE can transmit UL user datapackets to the target (H)eNB 2 and receive DL user data packets from thetarget (H)eNB 2.

In Block 1310, the target (H)eNB 2 informs the EPC 4 of a change of theserving cell of the UE and sends an S1AP: Path Switch Request message tothe EPC 4 (i.e., Mobility Management Entity (MME) 5) to request a changeof the route of the Evolved Packet System (EPS) bearer. The MME 5performs signaling with a Serving Gateway (S-GW) (not shown) and therebymodifies the route of the EPS bearer (i.e., route of the S1 bearer). InBlock 1311, the MME 5 sends an S1AP: Path Switch Request Acknowledgemessage to the target (H)eNB 2. In Block 1312, in response to receptionof the Path Switch Request Acknowledge message, the target (H)eNB 2sends to the X2 GW 3 an X2AP Message Transfer message carrying a UEContext Release message. In Block 1313, the X2 GW 3 transfers the X2APMessage Transfer message carrying the UE Context Release message to thesource (H)eNB 1. In response to reception of the UE Context Releasemessage, the source (H)eNB 1 releases the radio resources allocated tothe UE.

Note that in response to transmission of the UE Context Release message(Block 1312), the target (H)eNB 2 may release its GTP-U tunnelconfiguration for the data forwarding. In response to reception of theX2AP Message Transfer message carrying the UE Context Release message(Block 1312), the X2 GW 3 may release its GTP-U tunnel configuration forthe data forwarding. In response to reception of the UE Context Releasemessage (Block 1313), the source (H)eNB 1 may release its GTP-U tunnelconfiguration for the data forwarding.

Next, specific examples of a modification to the X2AP Message Transfermessage are described with reference to FIG. 14 and FIGS. 15A and 15B.FIG. 14 shows an example of a modification to the X2AP Message Transfermessage. The “U-Plane Relay Capability” IE is used by the X2 GW 3 toinform the (H)eNBs 1 and 2 of the presence or absence of its U-plane(X2-U) relay capability. The “Direct Path Unavailability” IE is used bythe (H)eNBs 1 and 2 to inform the X2 GW 3 of the availability of thedirect path 100. The “E-RABs To Be Setup List” IE is used by the X2 GW 3to inform the (H)eNBs 1 and 2 of the Endpoint configuration of the X2 GW3.

The “E-RABs To Be Setup List” IE includes the “E-RABs To Be Setup Item”IE. The “E-RABs To Be Setup Item” IE includes the “E-RAB ID” IE, the “ULGTP Tunnel Endpoint” IE, and the “DL GTP Tunnel Endpoint” IE. The “ULGTP Tunnel Endpoint” IE indicates the Endpoint configuration (i.e., TNLaddress and TEID) of the X2 GW 3 regarding the X2 transport bearer forUL data (i.e., UL PDUs) forwarding. The “DL GTP Tunnel Endpoint” IEindicates the Endpoint configuration (i.e., TNL address and TEID) of theX2 GW 3 regarding the X2 transport bearer for DL data (i.e., DL PDUs)forwarding.

FIGS. 15A and 15B show another example of a modification to the X2APMessage Transfer message. As shown in FIG. 15A, the X2AP MessageTransfer message is extended to include the “Message Type of X2APMessage” IE. The “Message Type of X2AP Message” IE indicates the type ofthe X2AP message carried by the X2AP Message Transfer message. In thisway, the X2 GW 3 can operate so as to refer to or decode only anecessary X2AP message(s). Specifically, the X2 GW 3 may refer to ordecode the “X2AP message” IE within the X2AP Message Transfer message,only when the “Message Type of X2AP Message” IE indicates the HandoverRequest message or the Handover Request Acknowledge message.

Additionally or alternatively, as shown in FIG. 15B, the X2AP MessageTransfer message is extended to include the “DL Forwarding” IE. The “DLForwarding” IE is used by the source (H)eNB 1 when the “X2AP message” IEcarries a Handover Request message. This “DL Forwarding” IE indicatesthe same content as the “DL Forwarding” IE that is contained in theHandover Request message embedded within the “X2AP message” IE. In thisway, the X2 GW 3 does not have to decode or refer to the HandoverRequest message in the “X2AP message” IE to check the “DL Forwarding”IE.

According to this, the X2AP Message Transfer message may be extended toinclude the “E-RAB Level QoS Parameters” IE as shown in FIG. 15B. The“E-RAB Level QoS Parameters” IE is used by the source (H)eNB 1 when the“X2AP message” IE carries a Handover Request message. The “E-RAB LevelQoS Parameters” IE indicates the same content as the “E-RAB Level QoSParameters” IE that is contained in the Handover Request messageembedded within the “X2AP message” IE.

Further, according to this, the “E-RAB ID” IE shown in FIG. 15B may beused by the source (H)eNB 1 when the “X2AP message” IE carries aHandover Request message. In this case, the “E-RAB ID” IE indicates thesame content as the “E-RAB ID” IE that is contained in the HandoverRequest message embedded within the “X2AP message” IE. Further, the“E-RAB ID” IE shown in FIG. 15B may be used by the target (H)eNB 2 whenthe “X2AP message” IE carries a Handover Request Acknowledge message. Inthis case, the “E-RAB ID” IE indicates the same content as the “E-RABID” IE that is contained in the Handover Request Acknowledge messageembedded within the “X2AP message” IE.

Still further, according to this, the “DL GTP Tunnel Endpoint” IE andthe “UL GTP Tunnel Endpoint” IE shown in FIG. 15B may be used by thetarget (H)eNB 2 when the “X2AP message” IE carries a Handover RequestAcknowledge message. In this case, the “DL GTP Tunnel Endpoint” IE andthe “UL GTP Tunnel Endpoint” IE indicate the same contents as the “DLGTP Tunnel Endpoint” IE and the “UL GTP Tunnel Endpoint” IE that arecontained in the Handover Request Acknowledge message embedded withinthe “X2AP message” IE.

As described above, by incorporating, into the X2AP Message Transfermessage, one or more information elements that the X2 GW 3 needs torefer to for the U-plane (X2-U) relay out of the information elementscontained in the Handover Request message and the Handover RequestAcknowledge message, the following advantage is obtained. That is, theX2 GW 3 only needs to transfer the X2AP Message IE in a transparentmanner and does not need to refer to or decode the X2AP Message IE. Ifthe X2 GW 3 always has to refer to or decode the X2AP Message IE, it mayconsiderably consume the processing power of the X2 GW 3, or a protocolerror may occur due to the difference in the X2AP protocol versionbetween the X2 GW 3 and the (H)eNBs. The X2 GW 3 can prevent theoccurrence of such problems by transferring the X2AP Message IE in atransparent manner.

Note that as shown in FIGS. 15A and 15B, when an information element(s)having the same contents as the information elements contained in theHandover Request message or the Handover Request Acknowledge message isadded in the X2AP Message Transfer message, this added informationelement(s) (e.g., at least one of “DL Forwarding” IE, “E-RAB Level QoSParameters” IE, “E-RAB ID” IE, “DL GTP Tunnel Endpoint” IE, and “UL GTPTunnel Endpoint” IE) may be used as the implicit relay request (or relayindication). That is, the X2 GW 3 may detect the presence or absence ofthe relay request from the (H)eNB 1 or 2 according to whether the X2APMessage Transfer message includes the added information element(s). Inthis case, the X2AP Message Transfer message does not necessarily haveto include the “Direct Path Unavailability” IE (or other explicit orimplicit relay requests).

Second Embodiment

This embodiment provides a specific example of a procedure for informingthe target (H)eNB 2 of the X2-U TNL address (e.g., IP address) of the X2GW 3. In the first embodiment, an example in which the X2-U TNL addressof the X2 GW 3 is set in the target (H)eNB 2 by the OAM and an examplein which the X2-U TNL address of the X2 GW 3 is sent from the X2 GW 3 tothe target (H)eNB 2 by using an X2AP Message Transfer message are shown.As an alternative of these examples, an improved Enhanced TNL AddressDiscovery procedure may be used.

The Enhanced TNL Address Discovery procedure is specified in Section4.6.6.1 of Non-patent Literature 1. In the Enhanced TNL AddressDiscovery procedure, an (H)eNB incorporates the TNL address of the X2GW, to which this (H)eNB is connected, into the S1AP: eNB CONFIGURATIONTRANSFER message and sends the eNB CONFIGURATION TRANSFER messageincluding the TNL address of the X2 GW to an MME. The MME acquires thetarget eNB ID and the TNL address of the X2 GW contained in the receivedeNB CONFIGURATION TRANSFER message and transfers the TNL address of theX2 GW to the target eNB ID by using the S1AP: MME CONFIGURATION TRANSFERmessage. In this way, the two (H)eNBs can share the TNL address of theX2 GW and use indirect X2 through the X2 GW.

However, it should be noted that the TNL address of the X2 GW that istransferred through the existing Enhanced TNL Address Discoveryprocedure is the TNL address for transferring X2AP signaling messagesvia the SCTP connection (i.e., X2-C TNL address). In this embodiment,the existing Enhanced TNL Address Discovery procedure is modified totransfer the TNL address (i.e., X2-U TNL address) of the X2 GW used fortransferring TNL UDP/IP packets carrying G-PDUs.

FIG. 16 is a sequence diagram showing an example (Process 1600) of anEnhanced TNL Address Discovery procedure according to this embodiment.The procedure shown in FIG. 16 is similar to the existing Enhanced TNLAddress Discovery procedure, except that the X2 GW U-plane address(i.e., X2-U TNL address) is sent. That is, in Block 1601, the source(H)eNB 1 sends an S1AP: eNB CONFIGURATION TRANSFER message to the MME 5.This eNB CONFIGURATION TRANSFER message includes the U-plane address ofthe X2 GW 3 (i.e., X2-U TNL address). In Block 1602, the MME 5 sends anS1AP: MME CONFIGURATION TRANSFER message to the target (H)eNB 2. ThisMME CONFIGURATION TRANSFER message includes the U-plane address (i.e.,X2-U TNL address) of the X2 GW 3 received from the source (H)eNB 1.

In Block 1603, the target (H)eNB 2 adds the received U-plane address(i.e., X2-U TNL address) of the X2 GW 3 in its ACL. In Block 1604, thetarget (H)eNB 2 sends an S1AP: eNB CONFIGURATION TRANSFER message to theMME 5. This eNB CONFIGURATION TRANSFER message is a response for thesource (H)eNB 1. In Block 1605, the MME 5 sends an S1AP: MMECONFIGURATION TRANSFER to the source (H)eNB 1. This MME CONFIGURATIONTRANSFER message includes the information element that is received fromthe target (H)eNB 2 by the eNB CONFIGURATION TRANSFER message (e.g., theU-plane address of the X2 GW 3 that the target (H)eNB 2 has receivedfrom the source (H)eNB 1).

FIGS. 17A and 17B show a specific example of a modification to the “X2TNL Configuration Info” IE specified in Section 9.2.3.29 of 3GPP TS36.413 V12.4.0. The “X2 TNL Configuration Info” IE is included in theS1AP: eNB CONFIGURATION TRANSFER message and the S1AP: MME CONFIGURATIONTRANSFER message. As shown in FIG. 17B, the “X2 TNL Configuration Info”IE may be extended so as to include the “Transport Layer Address” IEindicating the TNL address regarding the indirect X2 U-plane endpoint(i.e., X2-U TNL address of the X2 GW 3).

Lastly, configuration examples of the (H)eNBs 1 and 2 and the X2 GW 3according to the above embodiments are described. FIG. 18 is Blockdiagram showing a configuration example of the (H)eNB 1. The (H)eNB 2may have a configuration similar to that shown in FIG. 18. As shown inFIG. 18, the (H)eNB 1 includes an RF transceiver 1801, a networkinterface 1803, a processor 1804, and a memory 1805. The RF transceiver1801 performs analog RF signal processing to communicate with UEs. TheRF transceiver 1801 may include a plurality of transceivers. The RFtransceiver 1801 is connected to an antenna 1802 and the processor 1804.The RF transceiver 1801 receives modulated symbol data (or OFDM symboldata) from the processor 1804, generates a transmission RF signal, andsupplies the generated transmission RF signal to the antenna 1802.Further, the RF transceiver 1801 generates a baseband reception signalbased on a reception RF signal received by the antenna 1802 and suppliesthis signal to the processor 1804.

The network interface 1803 is used to communicate with a network node(e.g., MME and S/P-GW). The network interface 1803 may include, forexample, a network interface card (NIC) conforming to the IEEE 802.3series.

The processor 1804 performs data-plane processing (including digitalbaseband signal processing and control-plane processing for radiocommunication. For example, in the case of LTE or LTE-Advanced, thedigital baseband signal processing performed by the processor 1804 mayinclude signal processing of the PDCP layer, RLC layer, MAC layer, andPHY layer. Further, the signal processing performed by the processor1804 may include signal processing of the GTP-U⋅UDP/IP layer in the X2-Uinterface and S1-U interface. Further, the control plane processingperformed by the processor 1804 may include processing of the X2APprotocol, S1-MME protocol, and RRC protocol.

The processor 1804 may include a plurality of processors. For example,the processor 1804 may include a modem-processor (e.g., DSP) thatperforms the digital baseband signal processing, a processor (e.g., DSP)that performs the signal processing of the GTP-U.UDP/IP layer in theX2-U interface and S1-U interface, and a protocol-stack-processor (e.g.,CPU or MPU) that performs the control-plane processing.

The memory 1805 is composed of a combination of a volatile memory and anonvolatile memory. The memory 1805 may include a plurality ofphysically-independent memory devices. The volatile memory is, forexample, a Static Random Access Memory (SRAM), a Dynamic RAM (DRAM), ora combination thereof. The nonvolatile memory is, for example, a ReadOnly Memory (MROM), an Electrically Erasable Programmable ROM (EEPROM),a flash memory, a hard disk drive, or a combination thereof. The memory1805 may include a storage located apart from the processor 1804. Inthis case, the processor 1804 may access the memory 1805 through thenetwork interface 1803 or an I/O interface (not shown).

The memory 1805 may store a software module (i.e., computer program)including a set of instructions and data to perform processing performedby the (H)eNB 1 described in the above embodiments. In someimplementations, the processor 1804 may be configured to load thesoftware module from the memory 1805 and executing the loaded softwaremodule, thereby performing processing of the (H)eNB 1 described in theabove embodiments.

FIG. 19 is Block diagram showing a configuration example of the X2 GW 3.As shown in FIG. 16, the X2 GW 3 includes a network interface 1901, aprocessor 1902, and a memory 1903. The network interface 1901 is usedfor communication with network nodes (e.g., (H)eNBs 1 and 2). Thenetwork interface 1901 may include, for example, a network interfacecard (NIC) conforming to the IEEE 802.3 series.

The processor 1902 loads software (i.e., computer program) from thememory 1903 and executes the loaded software, thereby performingprocessing of the X2 GW 3 described in the above embodiments. Theprocessor 1902 may be, for example, a microprocessor, an MPU, or a CPU.The processor 1902 may include a plurality of processors.

The memory 1903 is composed of a combination of a volatile memory and anonvolatile memory. The memory 1903 may include a storage located apartfrom the processor 1902. In this case, the processor 1902 may access thememory 1903 through an I/O interface (not shown).

As described above with reference to FIGS. 18 and 19, each of theprocessors included in the (H)eNBs 1 and 2 and the X2 GW 3 in the aboveembodiments executes one or more programs including a set ofinstructions to cause a computer to perform an algorithm described abovewith reference to the drawings. These programs may be stored in varioustypes of non-transitory computer readable media and thereby supplied tocomputers. The non-transitory computer readable media includes varioustypes of tangible storage media. Examples of the non-transitory computerreadable media include a magnetic recording medium (such as a flexibledisk, a magnetic tape, and a hard disk drive), a magneto-optic recordingmedium (such as a magneto-optic disk), a Compact Disc Read Only Memory(CD-ROM), CD-R, CD-R/W, and a semiconductor memory (such as a mask ROM,a Programmable ROM (PROM), an Erasable PROM (EPROM), a flash ROM, and aRandom Access Memory (RAM)). These programs may be supplied to computersby using various types of transitory computer readable media. Examplesof the transitory computer readable media include an electrical signal,an optical signal, and an electromagnetic wave. The transitory computerreadable media can be used to supply programs to a computer through awired communication line (e.g., electric wires and optical fibers) or awireless communication line.

Other Embodiments

Each of the above embodiments may be used individually, or two or moreof the embodiments may be appropriately combined with one another.

In the examples shown the above embodiments, the GTP-U protocol is usedin the X2-U interface of the X2 GW. However, a protocol different fromthe GTP-U protocol, such as Proxy Mobile IPv6 (PMIPv6), may be used.

The above embodiments may be applied to other radio communicationsystems such as a UMTS system and a GSM system. The base station((H)eNB) described in the above embodiments may include a control nodehaving a radio resource management function (e.g., Radio NetworkController (RNC) in UMTS or Base Station Controller (BSC) in GSM system)and a radio transmission node (e.g., NodeB in UMTS or Base transceiverstation (BTS) in GSM system).

For example, as shown in 3GPP TS 25.467, when a Home NodeB (HNB)establishes an Iur connection with an RNC through a Home NodeB Gateway(HNB-GW), relocation can be performed between the HNB and the RNCthrough the HNB-GW. In this case, the HNB sends an RNSAP: EnhancedRelocation Request message via an Iurh interface through the HNB-GW.Then, the HNB-GW transfers the RNSAP: Enhanced Relocation Requestmessage via an Iur interface by using a Signaling Connection ControlPart (SCCP). In this case, the HNB-GW may further perform a U-planerelay between the HNB and the RNC.

The above embodiments may be applied to cases in which a gateway is usedbetween a UMTS system and an LTE/LTE-Advanced system. For example, whena handover is performed between an HeNB of the LTE and an RNC of theUMTS, the gateway may perform a U-plane relay between the HeNB and theRNC.

The above embodiments may be applied to cases in which a gateway is usedbetween a CDMA2000 system and an LTE/LTE-Advanced system. For example,the gateway may perform a U-plane relay when a handover is performedbetween an HeNB of the LTE and a base station of the CDMA2000 system.

The above embodiments may be applied to cases in which a gateway is usedbetween a Wireless Local Area Network (WLAN) system and anLTE/LTE-Advanced system. For example, when a handover is performedbetween an HeNB of the LTE and an access point of the WLAN, the gatewaymay perform a U-plane relay between the HeNB and the access point.

Further, the above embodiments can be applied to cases in which aninter-base-station gateway is used for an inter-base-station handover inany Radio Access Technology (RAT). Further, the above embodiments can beapplied to cases in which an inter-base-station gateway is used for aninter-base-station handover between any RATs.

Further, the above embodiments can be applied to cases in which an X2gateway is used for a handover between a Relay Node (RN) and a Donor eNB(DeNB). The RN and the DeNB are described in 3GPP TS 36.300 (Non-patentLiterature 1).

Further, as already described above, the above embodiments can beapplied to cases in which an X2 gateway is used to transfer user datapackets between a Master eNB (MeNB) and a Secondary eNB (SeNB) in thecase of Dual Connectivity. The Dual Connectivity is described in 3GPP TS36.300 (Non-patent Literature 1).

Further, the above embodiments are merely examples of applications ofthe technical ideas obtained by the inventor. Needless to say, thesetechnical ideas are not limited to the above embodiments and variousmodifications can be made thereto.

The whole or part of the embodiments disclosed above can be describedas, but not limited to, the following Supplementary notes.

(Supplementary Note 1)

A method performed by a base station apparatus, the method comprising:

considering availability of a direct path between the base stationapparatus and another base station when determining whether a relayoperation is necessary, the relay operation being an operation in whichan inter-base-station gateway relays a data packet destined for or sentfrom a radio terminal between the base station apparatus and the otherbase station.

(Supplementary Note 2)

A method performed by a base station apparatus, the method comprising;

considering a capability of a relay operation of an inter-base-stationgateway when determining whether the relay operation is necessary, therelay operation being an operation in which the inter-base-stationgateway relays a data packet destined for or sent from a radio terminalbetween the base station apparatus and another base station.

(Supplementary Note 3)

A method performed by a base station apparatus, the method comprising:

sending a first information element to an inter-base-station gateway,wherein

the first information element indicates availability of a direct pathbetween the base station apparatus and another base station.

(Supplementary Note 4)

A method performed by an inter-base-station gateway apparatus, themethod comprising:

notifying a base station of a capability of a relay operation, wherein

the relay operation comprises relaying, by the inter-base-stationgateway apparatus, a data packet destined for or sent from a radioterminal between a first base station and a second base station.

(Supplementary Note 5)

An inter-base-station gateway apparatus comprising:

a memory; and

at least one processor coupled to the memory, wherein

the at least one processor is configured to receive a first informationelement from at least one of a first base station and a second basestation, and

the first information element explicitly or implicitly indicates whethera relay operation is necessary, the relay operation being an operationin which the inter-base-station gateway apparatus relays a data packetdestined for or sent from a radio terminal between the first basestation and the second base station.

(Supplementary Note 6)

The inter-base-station gateway apparatus according to Supplementary note5, wherein the first information element explicitly indicatesavailability of a direct path between the first and second basestations.

(Supplementary Note 7)

The inter-base-station gateway apparatus according to Supplementary note5 or 6, wherein the at least one processor is configured to receive thefirst information element when the radio terminal is handed over fromthe first base station to the second base station.

(Supplementary Note 8)

The inter-base-station gateway apparatus described in any one ofSupplementary notes 5 to 7, wherein the at least one processor isconfigured to send a second information element indicating a capabilityof the relay operation to at least one of the first and second basestations.

(Supplementary Note 9)

The inter-base-station gateway apparatus according to Supplementary note8, wherein the at least one processor is configured to send the secondinformation element during a procedure for registering at least one ofthe first and second base stations in the inter-base-station gatewayapparatus.

(Supplementary Note 10)

The inter-base-station gateway apparatus according to any one ofSupplementary notes 5 to 9, wherein the at least one processor isconfigured to determine whether to perform the relay operation based onthe first information element.

(Supplementary Note 11)

The inter-base-station gateway apparatus according to any one ofSupplementary notes 5 to 10, wherein the at least one processor isconfigured to, when the relay operation is performed by theinter-base-station gateway apparatus, incorporate, into a first transfermessage carrying a handover request message from the first base stationto the second base station, an endpoint configuration of theinter-base-station gateway apparatus regarding a first transport bearerfor transferring the data packet between the inter-base-station gatewayapparatus and the second base station.

(Supplementary Note 12)

The inter-base-station gateway apparatus according to Supplementary note11, wherein the endpoint configuration is used to update a packet filterin the second base station.

(Supplementary Note 13)

The inter-base-station gateway apparatus according to Supplementary note11 or 12, wherein the endpoint configuration includes a transport-layeraddress of the inter-base-station gateway apparatus.

(Supplementary Note 14)

The inter-base-station gateway apparatus according to any one ofSupplementary notes 11 to 13, wherein the endpoint configurationincludes an endpoint configuration for downlink forwarding and anendpoint configuration for uplink forwarding.

(Supplementary Note 15)

The inter-base-station gateway apparatus according to any one ofSupplementary notes 5 to 14, wherein the at least one processor isconfigured to, when the relay operation is performed by theinter-base-station gateway apparatus, incorporate, into a secondtransfer message carrying a handover request acknowledge message fromthe second base station to the first base station, an endpointconfiguration of the inter-base-station gateway apparatus regarding asecond transport bearer for transferring the data packet between theinter-base-station gateway apparatus and the first base station.

(Supplementary Note 16)

A method performed by a base station apparatus, the method comprising:

sending a first information element to an inter-base-station gateway,wherein

the first information element explicitly or implicitly indicates whethera relay operation is necessary, the relay operation being an operationin which the inter-base-station gateway relays a data packet destinedfor or sent from a radio terminal between the base station apparatus andanother base station.

(Supplementary Note 17)

The method according to Supplementary note 16, wherein the firstinformation element explicitly indicates availability of a direct pathbetween the base station apparatus and the other base station.

(Supplementary Note 18)

The method according to Supplementary note 16 or 17, wherein the sendingcomprises sending the first information element when the radio terminalis handed over from the base station apparatus to the other basestation, or from the other base station to the base station apparatus.

(Supplementary Note 19)

The method according to Supplementary note 18, wherein the sendingcomprises incorporating the first information element into a transfermessage that is to be sent to the inter-base-station gateway to carry ahandover request message or handover request acknowledge message for theother base station.

(Supplementary Note 20)

The method according to Supplementary note 19, wherein the firstinformation element implicitly indicates that the relay operation isnecessary by indicating the same content as a second information elementincluded in the handover request message or the handover requestacknowledge message carried by the transfer message.

(Supplementary Note 21)

The method according to Supplementary note 19, further comprisingincorporating, into the transfer message, a third information elementindicating the same content as a second information element contained inthe handover request message or the handover request acknowledge messagecarried by the transfer message.

(Supplementary Note 22)

The method according to Supplementary note 20 or 21, wherein the secondinformation element includes at least one of: an information elementindicating necessity of forwarding the data packet; an informationelement indicating an identifier of a bearer configured for the radioterminal; and an information element indicating a Quality of Service(QoS) parameter of the bearer.

(Supplementary Note 23)

The method according to any one of Supplementary notes 19 to 22, furthercomprising incorporating, into the transfer message, an informationelement indicating a type of an inter-base-station signaling messagecarried by the transfer message.

(Supplementary Note 24)

The method according to any one of Supplementary notes 16 to 23, furthercomprising:

determining whether to use the relay operation by the inter-base-stationgateway to transmit or receive the data packet; and when the relayoperation is not used, forwarding the data packet via a direct pathbetween the base station apparatus and the other base station.

(Supplementary Note 25)

A method performed by an inter-base-station gateway apparatus, themethod comprising:

receiving a first information element from at least one of a first basestation and a second base station, wherein

the first information element explicitly or implicitly indicates whethera relay operation is necessary, the relay operation being an operationin which the inter-base-station gateway apparatus relays a data packetdestined for or sent from a radio terminal between the first basestation and the second base station.

(Supplementary Note 26)

The method according to Supplementary note 25, wherein the firstinformation element explicitly indicates availability of a direct pathbetween the first and second base stations.

(Supplementary Note 27)

The method according to Supplementary note 25 or 26, wherein thereceiving comprising receiving the first information element when theradio terminal is handed over from the first base station to the secondbase station.

(Supplementary Note 28)

The method according to any one of Supplementary notes 25 to 27, furthercomprising sending a second information element indicating a capabilityof the relay operation to at least one of the first and second basestations.

(Supplementary Note 29)

The method according to Supplementary note 28, wherein the sendingcomprises sending the second information element during a procedure forregistering at least one of the first and second base stations in theinter-base-station gateway apparatus.

(Supplementary Note 30)

The method according to any one of Supplementary notes 25 to 29, furthercomprising determining whether to perform the relay operation based onthe first information element.

(Supplementary Note 31)

The method according to any one of Supplementary notes 25 to 30, furthercomprising, when the relay operation is performed by theinter-base-station gateway apparatus, incorporating, into a firsttransfer message carrying a handover request message from the first basestation to the second base station, an endpoint configuration of theinter-base-station gateway apparatus regarding a first transport bearerfor transferring the data packet between the inter-base-station gatewayapparatus and the second base station.

(Supplementary Note 32)

The method according to Supplementary note 31, wherein the endpointconfiguration is used to update a packet filter in the second basestation.

(Supplementary Note 33)

The method according to Supplementary note 31 or 32, wherein theendpoint configuration includes a transport-layer address of theinter-base-station gateway apparatus.

(Supplementary Note 34)

The method according to any one of Supplementary notes 31 to 33, whereinthe endpoint configuration includes an endpoint configuration fordownlink forwarding and an endpoint configuration for uplink forwarding.

(Supplementary Note 35)

The method according to any one of Supplementary notes 25 to 34, furthercomprising, when the relay operation is performed by theinter-base-station gateway apparatus, incorporating, into a secondtransfer message carrying a handover request acknowledge message fromthe second base station to the first base station, an endpointconfiguration of the inter-base-station gateway apparatus regarding asecond transport bearer for transferring the data packet between theinter-base-station gateway apparatus and the first base station.

This application is based upon and claims the benefit of priority fromJapanese patent application No. 2015-058155, filed on Mar. 20, 2015, thedisclosure of which is incorporated herein in its entirety by reference.

REFERENCE SIGNS LIST

-   1 (H)eNB-   2 (H)eNB-   3 X2 GATEWAY (X2 GW)-   4 EVOLVED PACKET CORE (EPC)-   5 MOBILITY MANAGEMENT ENTITY (MME)-   1804 PROCESSOR-   1805 MEMORY-   1902 PROCESSOR-   1903 MEMORY

The invention claimed is:
 1. A base station apparatus comprising: amemory; and at least one processor coupled to the memory, wherein the atleast one processor is configured to send a first information element toan inter-base-station gateway, the first information element explicitlyor implicitly indicates whether a relay operation is necessary, therelay operation being an operation in which the inter-base-stationgateway relays a data packet destined for or sent from a radio terminalbetween the base station apparatus and an other base station, and the atleast one processor is configured to, when generating the firstinformation element, consider whether it is necessary to conceal atransport-layer address of the base station apparatus from the otherbase station.
 2. The base station apparatus according to claim 1,wherein the first information element explicitly indicates availabilityof a direct path between the base station apparatus and the other basestation.
 3. The base station apparatus according to claim 1, wherein theat least one processor is configured to send the first informationelement when the radio terminal is handed over from the base stationapparatus to the other base station, or from the other base station tothe base station apparatus.
 4. The base station apparatus according toclaim 3, wherein the at least one processor is configured to incorporatethe first information element into a transfer message that is to be sentto the inter-base-station gateway to carry a handover request message orhandover request acknowledge message for the other base station.
 5. Thebase station apparatus according to claim 4, wherein the firstinformation element implicitly indicates that the relay operation isnecessary by indicating the same content as a second information elementincluded in the handover request message or the handover requestacknowledge message carried by the transfer message.
 6. The base stationapparatus according to claim 5, wherein the second information elementincludes at least one of: an information element indicating necessity offorwarding the data packet; an information element indicating anidentifier of a bearer configured for the radio terminal; and aninformation element indicating a Quality of Service (QoS) parameter ofthe bearer.
 7. The base station apparatus according to claim 4, whereinthe at least one processor is configured to incorporate, into thetransfer message, a third information element indicating the samecontent as a second information element contained in the handoverrequest message or the handover request acknowledge message carried bythe transfer message.
 8. The base station apparatus according to claim1, wherein the at least one processor is configured to incorporate, intothe transfer message, an information element indicating a type of aninter-base-station signaling message carried by the transfer message. 9.The base station apparatus according to claim 1, wherein the at leastone processor is configured to determine whether to use the relayoperation by the inter-base-station gateway to transmit or receive thedata packet, and when the relay operation is not used, the data packetis forwarded via a direct path between the base station apparatus andthe other base station.
 10. The base station apparatus according toclaim 1, wherein the at least one processor is configured to, whengenerating the first information element, consider whether theinter-base-station gateway has a capability of the relay operation. 11.The base station apparatus according to claim 1, wherein the at leastone processor is configured to receive from the inter-base-stationgateway a fourth information element indicating a capability of therelay operation.
 12. The base station apparatus according to claim 11,wherein the at least one processor is configured to receive the fourthinformation element during a procedure for registering the base stationapparatus in the inter-base-station gateway.
 13. The base stationapparatus according to claim 1, wherein the at least one processor isconfigured to, when generating the first information element, consider astate of a direct path between the base station apparatus and the otherbase station.
 14. The base station apparatus according to claim 13,wherein the state of the direct path includes at least one ofavailability of the direct path, throughput of the direct path, and aload of the direct path.
 15. The base station apparatus according toclaim 1, wherein the at least one processor is configured to, whengenerating the first information element, consider a type of the otherbase station.
 16. A method performed by a base station apparatus, themethod comprising: sending a first information element to aninter-base-station gateway, wherein the first information elementexplicitly or implicitly indicates whether a relay operation isnecessary, the relay operation being an operation in which theinter-base-station gateway relays a data packet destined for or sentfrom a radio terminal between the base station apparatus and an otherbase station, wherein the method further comprises, when generating thefirst information element, considering whether it is necessary toconceal a transport-layer address of the base station apparatus from theother base station.